3 Usability Design — Extending Rational Unified Process with a New Discipline

A new discipline, Usability Design, is proposed as an extension to Rational Unified Process (RUP). The aim is to make RUP more user-centred. The discipline springs out of best practices for user-centred design and contains activities that have been carefully tested. Five new roles are introduced to take responsibility for the different activities. An example is given to show the content of the workflow, the workflow details and the activities. The Usability Design discipline help projects to focus on usability and the users throughout the system development lifecycle. Introduction – Usability and User-Centred Design There are both financial and ethical reasons why usability is worth investing in. An application with high usability can make the user more effective and in less need of support and education. The risk of users making mistakes will be reduced and a system with high usability will provide a less stressful environment for the users. In the International Standard ISO 9241-11 [12] usability is defined as “The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” The effectiveness of a system relates to the work objectives (goals). The efficiency relates to effectiveness in relation to the resources needed to perform the tasks. Satisfaction, according to ISO 9241, concerns acceptability and comfort. Gould, Boies & Ukelson [6] claim that to build a usable system it is crucial to: have early – and continual – focus on users do empirical measurement do iterative design – redesign do integrated design – wherein all aspects of usability evolve together For the successful integration of usability it must be incorporated in the software development process [14]. When we speak about user-centred design we refer to a process focusing on usability throughout the entire development Paper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 2 process and further throughout the system life cycle [7]. Although user-centred design (UCD) is no guarantee for usable systems, we argue that without it, high usability is usually nothing more than a coincidence. Benyon [1] means that HCI should contribute to systems design with modeling tools to complement existing methods and tools of systems analysis, instead of “inventing wheels which have already been painfully discovered by others” (p. 119). Sutcliff and Wang [24] mean that HCI principals are poorly spread partly because of lack of integration between HCI research and practice and methods in software engineering. We believe that our approach is slightly different from others’ within the usability community, e.g. Mayhew [19], Beyer & Holtzblatt [2] and Carroll & Rosson [4], since we do not promote “yet another usability method”, to be accepted and used, or rejected. Instead we acknowledge that RUP is a widely used software development process, and we promote user-centered design within that development framework. Yet others, for example Kruchten, Ahlqvist & Bylund [16], have suggested usability related activities within RUP. However, these are almost solely concerned with the UI design and do not take full responsibility for the lifecycle perspective on user-centered design. We argue that our approach benefits from being fully integrated within a commonly used software development process. By integrating user-centered design to the level of “boxes and arrows” we gain credibility as well as acceptance from software practitioners. The Rational Unified Process Rational Unified Process is a software engineering process [15] that significantly has contributed to the software development practice. Today, it is widely used and has contributed to creating a more unified view on software development. However, from a usability point of view RUP has several drawbacks. Problems with the use of the process have been observed in several projects [8]. It does not provide the support needed to produce a usable system. How User-Centred is RUP? In a study by Gulliksen, Göransson, Boivie, Blomkvist, Persson & Cajander [7] the outcome of a project was compared with a list of principles for user1 RUP has become more or less the de-facto standard for software development in Sweden. There are currently 6 000 licence owners in Sweden and almost all of our studied development organisations are using RUP. According to Rational themselves (Rational Software was recently acquired by IBM and are the original developers of RUP), RUP has been used in more than 10 000 customer projects world wide and it is taught as part of the computer science curriculum in hundreds of universities. Paper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 3 centred design. It shows how a project using RUP with clear intentions to apply a UCD approach ran into several problems that made it difficult to pursue with that approach. Some of the problems are briefly described below: No lifecycle perspective on UCD. The developers focused on shortterm goals, such as, producing the models and specifications prescribed by RUP. The long-term goals and needs of the users regarding their future work situation were ignored or forgotten. Usability designers were ignored. Despite the work produced by the usability designers being of high quality, their results and opinions were ignored in the late stages of the project. “Use case mania”. When the project started the organisation did not have enough experience with use case modelling. The modelling went out of hand and the results could not be used efficiently in the development process. The project got literally bogged down in use cases, but did not really know what to do with them. Poor understanding of the design documentation. The user interface design was specified in the Unified Modelling Language (UML) and the users were invited to review it. The users had severe difficulties predicting their future use situation based on the UML notation. Problems establishing a user-centred attitude. Single individuals in a project can make a crucial difference when it comes to UCD. In this project people were more concerned about their personal goals than about the needs of the users. Our view is that RUP is not a user-centred method in itself. On the contrary, there are fundamentals in RUP that actually prohibits a true UCD process: RUP is an “architecture-centric” and a “use case driven” process rather then user-centred. ”Use cases drive the Rational Unified process end-to-end over the whole lifecycle, but the design activities are centred around the notion of architecture system architecture, or for software-intensive systems, software architecture.” [13] The definition of iteration within RUP differs significantly from how it is defined in for instance UCD. In RUP, an iteration is “A distinct sequence of activities with a base-lined plan and valuation criteria resulting in a release (internal or external)” [23]. The activities inside the iteration are laid out as a waterfall. This prohibits iterations to formally occur within workflows and activities. From a UCD point of view an iteration is a refinement of a certain part of the system (an increment), going through the stages analysis, design and evaluation until goals are reached. Paper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 4 Usability related activities do only occur within the Requirements discipline (workflow) and primarily in the Elaboration phase. To consider usability only when gathering requirements is fundamentally wrong. From a UCD perspective usability related activities should be included from the start of the project to the very end. RUP focuses too much on artefacts. There is a risk that the “big picture” gets lost and that each role puts too much effort in writing documents (fill out forms). Also, the project members are encouraged to get “his/her work done” not to collaborate. In UCD a lot of the work is done in multi-disciplinary teams. UCD is mainly userand process-driven, with a focus on the activities. The methods vary and so does the outcome (the artefacts). No support for user interface design. The focus in RUP is on the use cases and the interaction between the actors and the use cases but it does not give enough support when it comes to designing the user interface supporting that interaction [17]. UML does not really distinguish between human and non-human actors. Designing an interface to another system is completely different from designing an interface for real user. Use Cases—Promising But Not Enough For software developers use cases is the longed-for answer to the quest for a formal notation to express issues relating to the use of the systems. It must be acknowledged that use cases constitute a tool for software developers that is a vast improvement compared to its predecessors. However, based on our experience in practice we have encountered several problems with use cases in relation to a user-centred development. Some of these are discussed below. The notation of use cases is difficult for users to understand. The reason for this is that users do not interact with the system. They perform work tasks supported by the computer. As a consequence of this it is difficult for users to relate to use cases and understand practically how these will influence the design of the user interface and the interaction. Use cases are sometimes a good way of communicating internally between usability designers and software developers. Unfortunately, we have observed that software developers and usability designers have different requirements on the size of the use cases. Many software developers prefer small use cases when specifying the functionality. For usability designers use cases instead have to be large to correspond to users’ work tasks. We have observed that using small use cases can cause problems since users usually have to communicate with several use cases to perform one work task. The way use cases are described can have implications on the design space. We have seen several Paper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 5 examples where the use case description defines exactly what interaction elements to present on the screen. Constantine & Lockwood [5] claim that the concept of use case is not clearly enough defined. As a result there are huge variations in style for writing narratives that describe use cases. They also emphasise that use cases can cause problems for the design of the user interface if they are describing the interaction between the user and a particular interface. Instead Essential use cases are introduced where the focus is on the intentions of the users rather then the interaction, making them device independent. However, using use cases as the only means of communication can be insufficient Using prototypes as a complement to illustrate ideas and functionality early on in the process is necessary. A prototype is usually a lot easier for a user to understand and a lot of poor design solutions can be avoided at an early stage. Muller, Haslwanter and Dayton [20] claim that there are other problems with the use case driven approach. One being that use cases are modelled with the software system as the focus of attention. They mean that the use cases give too little priority to the end users and that each use case is a definition of user actions by software engineers. To overcome these problems it is necessary to model the use cases in participation with the end-users. Otherwise there is a great risk that the application will not support the users efficiently in their work. RUP—If You Can’t Beat Them, Join Them! The conclusion from this is that RUP and use cases as such are not ideal for user-centred design. But, to manage having an impact in practice we have decided to relate our development process to a RUP based approach, since this is one of the most widely used processes in the large, in-house development organisations we typically work with. What’s available in RUP today, with regards to usability and user-centred design? Plug-ins to RUP. The User Experience plug-in to RUP is developed and maintained by Rational. Primarily, it is focused on website projects, and does not cover the whole user-centred design process. IconMedialab have developed a similar plug-in also aimed at website projects [11]. Both of these plug-ins have a strong focus on creative design and business development, not so much on usability. Therefore, we see a need for a more general plug-in with a strong usability focus. Usability Engineering Roadmap and User-Centred Design Concept Paper. There is a so-called roadmap for Usability Engineering available in RUP (roadmaps provide a way of describing how to use the general-purpose process described in RUP to solve specific types of problems). A shortcoming of the roadmap is that it does not add any new user-centred activities to the process: “This roadmap explains how the Rational Unified Process (RUP) currently Paper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 6 addresses usability engineering techniques” [23]. We believe, that for RUP to become more user-centred, there are certain activities, roles and artefacts that must be added. However, the roadmap, together with the concept paper UserCentred Design, is a good starting point when aiming for a more user-centred approach within the current boundaries of RUP. User Interface Design in RUP. Recently, RUP has been extended to provide better support for UI-design [16]. Use case storyboards are introduced to extend use cases with information related to the user interface. This is a formal procedure that captures some of the relevant information. However, if this step-by-step procedure is followed there is still a risk that the user will have to work with a fragmented interface where each use case is realised by one interface. Also, we believe that UI-design is a creative process that cannot be described as a step-by-step procedure. Other Approaches. In our work with organisations we have seen other approaches for how to make RUP more user-centred, one being to make minor changes in the activities performed by the existing role; User Interface Designer. This is a good attempt, but not enough to make the process usercentred. Another approach would be to change all other disciplines to make the process more user-centred. This would probably be good, but the result would be a completely new method, i.e. it would no longer be RUP. The Usability Design Discipline In this paper we propose a new discipline, Usability Design (for short: UD discipline), extending RUP (see Figure 1). Our aim with the UD discipline is to complement RUP to make it more suitable for systems development where usability is acknowledged to be important. The way to do this is to apply a more user-centred approach to the process. Most of the analysis, design and evaluation work is performed during the inception phase and the early phases of elaboration. During the construction and transition phases there is less work done in the UD discipline. It mainly includes monitoring and making ad hoc design decisions. The actual coding of the GUI is not part of the UD discipline. The proposed discipline is drawn from our previous research and published literature. We have previously observed that UML and use cases do not give sufficient support for user interface design and proposed a method, User Interface Modelling, for gathering requirements relevant when designing for usability [17]. Methods and tools with a strong user focus for designing usable user interfaces have been presented, such as the workspace metaphor [18], corporate style guides [22], and analysis of information utilisation [9]. Also, problems with RUP and user-centred design have been identified and the usability designer has been introduced as an important role in software development projects [8]. Apart from this we have proposed 12 principles to use as a guide Paper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 7 in UCD projects [7]. This together with our extensive practical experience as usability consultants in large software development projects forms the base on which the UD discipline for RUP is developed. Figure 1: The Usability Design discipline merges into the overall architecture of the RUP. This illustration is a modified version of the process description overview found in RUP. Best Practices Included in the UD discipline is a best practice document with 12 principles to apply in UCD projects [7]. It covers aspects of the process that cannot be illustrated with the workflow, activities and roles. The best practices imply that: User-centred design is a process focusing on usability throughout the entire development process and further throughout the system life cycle. The following best practices communicate the core of this process: User focus—the goals of the activity, the work domain or context of use, the users’ goals, tasks and needs should control the development. Active user involvement—representative users should actively participate, early and continuously throughout the entire development process and throughout the system lifecycle. Evolutionary systems development—the systems development should be both iterative and incremental. Paper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 8 Simple design representations—the design must be represented in such ways that it can be easily understood by users and all other stakeholders. Prototyping—early and continuously, prototypes should be used to visualize and evaluate ideas and design solutions in cooperation with the end users. Evaluate use in context—base lined usability goals and design criteria should control the development. Explicit and conscious design activities—the development process should contain dedicated design activities. A professional attitude—the development process should be conducted by effective multidisciplinary teams. Usability champion—usability experts should be involved from the start of project to the very end. Holistic design—all aspects that influence the future use situation should be developed in parallel. Process customisation—the UCD process must be specified, adapted and implemented locally in each organization. Usability cannot be achieved without a user-centred process. There is, however, no onesize-fits-all process. A user-centred attitude must be established—UCD requires a usercentred attitude throughout the project team, the development organisation and the client organisation. Description of the Usability Design Discipline The UD discipline is concerned with developing systems with a focus on usability. Purpose The UD discipline is an extension to RUP. Its main purpose is to put focus on usability through user-centred design. It encapsulates the best practices for UCD and makes it possible to practice UCD within the RUP framework. Roles The new roles suggested in the UD discipline are: Usability Designer. This role is a usability champion and lead. The individual acting in this role must have extensive experience. She should be an HCI expert with a background in computer science and/or behaviour sciences and with hands on experience from the entire userPaper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 9 centred design process. The Usability Designer is responsible for planning and managing the activities in the UD discipline, as well as carrying out some of them. Field Study Specialist. This role should be experienced in using different usability methods and techniques for categorising user groups and understanding user needs. Typically this person should be able to plan, perform, and analyse user studies. She should also be able to come up with design solutions to meet the identified needs. A general background in HCI is preferable. Interaction Designer. The Interaction Designer is responsible for the conceptual, interaction and the detailed design. This includes: creating the overall interaction scheme and layout; defining the dynamics of the user interaction and the navigation paths and specifying the information structure. A combination of HCI knowledge and design experience is needed. Graphic Designer. This role is responsible for the visual shaping of the user interface and works closely together with the Interaction Designer. A background in creative design and experience from interactive media is needed. Usability Evaluation Specialist. This role is responsible for planning, preparing, executing and reporting usability evaluations. She should be an expert in performing evaluations in usability laboratories as well as in the field. The background for this role is HCI with a focus on behaviour science. Usability designer Interaction designer Graphic designer Field study specialist Usability evaluation specialist Figure 2: Illustrating the roles in the Usability Design discipline. Paper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 10 We can clearly see the benefits of having multiple specialised roles in projects. However, if each role is represented by one person there is a risk that important information will get lost when, for instance, the Field Study Specialist hand over the result to the Interaction Designer. Therefore, in many projects, the person acting as the Usability Designer also covers the other roles (see Figure 2). All roles must be able to work effectively with, and communicate well with users. Active user participation is crucial for the UD discipline. The Workflow The workflow shows, on a high level, the user-centred work performed in each iteration of the UD discipline (see Figure 3). Create usability design plan Conduct user studies Conceptual design Interaction design [ Start of project ] Perform competitor analysis Develop user assistance [ Inception and early elaboration ] Monitor usability work Detailed design Usability evaluation Refine usability design plan Figure 3: The core workflow of the Usability Design discipline. Following is a short description of the main activities: Usability design plan. A number of methods can be used to perform the different activities in the workflow. In this workflow detail the acPaper 3: Usability Design— Extending Rational Unified Process with a New Discipline User-Centred Systems Design – Designing Usable Interactive Systems in Practice by Bengt Göransson 11 tual selection of methods is done. The usability design plan is created at the start of the project and is then refined during each iteration. Activities are: Detailed planning of user-centred activities Plan user involvement Conduct project usability workshop Conduct user studies. The aim of this workflow detail is to understand the potential users of the system, their needs and the context of use. The goals for the system, design criteria and usability goals are specified. Information is gathered through interviews, observations, workshops, etc. Activities are: